Drop deprecated auto-self-downcasts - #213

@connorjward This is another thing that might be worth a look. The gunk that this drops will no longer be needed by loopy after inducer/loopy#1023, so I'd like to get rid of it before too long. It has been deprecated (with warnings) for a while. Merging this will break old loopy.

I'd be happy to coordinate with you on the timeline for merging and releasing this.

@connorjward This is another thing that might be worth a look. The gunk that this drops will no longer be needed by loopy after inducer/loopy#1023, so I'd like to get rid of it before too long. It has been deprecated (with warnings) for a while. Merging this will break old loopy.

I'd be happy to coordinate with you on the timeline for merging and releasing this.

Our next release is scheduled for early October. We are quite used to handling upstream breaking changes (looking at you PETSc) so I am not concerned. And since our releases use versioned releases of loopy this isn't an immediately breaking changes for our users (and if you make a new release that breaks us we can make a patch release with a pin in short order).

In short: early warning of things breaking is super welcome, but don't let us hold you up and merging early (and hence well in advance of our next release) is actually best.

In short: early warning of things breaking is super welcome, but don't let us hold you up and merging early (and hence well in advance of our next release) is actually best.

Does that mean you guys also have a version constraint on islpy? If not, it might be good to put that in place. Without that, the removal of the implicit casts that are happening here will break current released versions of loopy, once this shows up in a released version of islpy.

There's no big rush from my perspective, as current loopy main works fine with release islpy. That said, the removal of these casts does seem to speed things up a good bit, so it's desirable to have this before too long.

In short: early warning of things breaking is super welcome, but don't let us hold you up and merging early (and hence well in advance of our next release) is actually best.

Does that mean you guys also have a version constraint on islpy? If not, it might be good to put that in place. Without that, the removal of the implicit casts that are happening here will break current released versions of loopy, once this shows up in a released version of islpy.

There's no big rush from my perspective, as current loopy main works fine with release islpy. That said, the removal of these casts does seem to speed things up a good bit, so it's desirable to have this before too long.

We don't constrain islpy but I am not concerned. If a new islpy release breaks us then we will detect that very quickly because of how often we run CI. We can then add a version pin to our pyproject.toml and make a patch release immediately.